Action Message Format (AMF) is a binary format used to serialize objects graphs such ActionScript objects and XML, or send messages between an Adobe Flash client and a remote service, usually a Flash Media Server or third party alternatives.
The format is often used in conjunction with Adobe's RTMP to establish connections and control commands for the delivery of streaming media. In this case, the AMF data is encapsulated in a chunk which has a header which defines things as the message length and type (whether it is a "ping", "command" or media data).
Contents |
AMF was introduced with Flash Player 6, and this version is referred to as AMF0. It was unchanged until the release of Flash Player 9 and ActionScript 3.0, when new data types and language features prompted an update, called AMF3.[1]
Adobe Systems published the AMF binary data protocol specification[2] on December 13, 2007 and announced that it will support the developer community to make this protocol available for every major server platform.
The protocol specifies a number of data types that can be encoded and Adobe states that the format is rather meant at encoding object graphs. These can be nested objects which can include basic data types such as strings, numbers and booleans. XML is supported as a native type. Each type is denoted by a single byte using the example codes below (for AMF0):
AMF Objects are sets of key value pairs, where keys are encoded as strings but without a type-definition byte in front (0x02). All other data is preceded by a type definition byte and in the case of strings, 2 bytes denoting length. Null types have no bytes while numbers are encoded as double precision floating point.
Although, strictly speaking, AMF is only a data encoding format, it is usually found encapsulated in a RTMP Message or Flex RPC call. An example of the former can be found below (it is the "_result" message returned in response to the "connect" command sent from the flash client):
| Hex Code | ASCII |
|---|---|
| 03 00 00 00 00 01 05 14 00 00 00 00 02 00 07 5F 72 65 73 75 6C 74 00 3F F0 00 00 00 00 00 00 03 00 06 66 6D 73 56 65 72 02 00 0E 46 4D 53 2F 33 2C 35 2C 35 2C 32 30 30 34 00 0C 63 61 70 61 62 69 6C 69 74 69 65 73 00 40 3F 00 00 00 00 00 00 00 04 6D 6F 64 65 00 3F F0 00 00 00 00 00 00 00 00 09 03 00 05 6C 65 76 65 6C 02 00 06 73 74 61 74 75 73 00 04 63 6F 64 65 02 00 1D 4E 65 74 43 6F 6E 6E 65 63 74 69 6F 6E 2E 43 6F 6E 6E 65 63 74 2E 53 75 63 63 65 73 73 00 0B 64 65 73 63 72 69 70 74 69 6F 6E 02 00 15 43 6F 6E 6E 65 63 74 69 6F 6E 20 73 75 63 63 65 65 64 65 64 2E 00 04 64 61 74 61 08 00 00 00 00 00 07 76 65 72 73 69 6F 6E 02 00 0A 33 2C 35 2C 35 2C 32 30 30 34 00 00 09 00 08 63 6C 69 65 6E 74 69 64 00 41 D7 9B 78 7C C0 00 00 00 0E 6F 62 6A 65 63 74 45 6E 63 6F 64 69 6E 67 00 40 08 00 00 00 00 00 00 00 00 09 | . . . . . . . . . . . . . . . _ r e s u l t . ? . . . . . . . . . f m s V e r . . . F M S / 3 , 5 , 5 , 2 0 0 4 . . c a p a b i l i t i e s . @ ? . . . . . . . . m o d e . . . . . . . . . . . . . . l e v e l . . .s t a t u s . . . c o d e . . . N e t C o n n e c t i o n . C o n n e c t . S u c c e s s . . d e s c r i p t i o n . . . C o n n e c t i o n su c c e e d e d . . d a t a . . . . . . . version . . . 3 , 5 , 5 , 2 0 0 4 . . . . . . c l i e n t i d . . . . . . . . . . . o b j e c t E n c o d i n g . @ . . . . . . . . . . |
legend: object start/end object keys object values array
The AMF message starts with a 0x03 which denotes an RTMP packet with Header Type of 0, so we expect 12 bytes to follow. It is of Message Type 0x14 which denotes a command in the form of a string of value "_result" and two serialised objects as arguments. The message can be decoded as follows:
(command) “_result”
(transaction id) 1
(value)
[1] { fmsVer: "FMS/3,5,5,2004"
capabilities: 31.0
mode: 1.0 },
[2] { level: “status”,
code: “NetConnection.Connect.Succeeded",
description: “Connection succeeded”,
data: (array) {
version: “3,5,5,2004” },
clientId: 1584259571.0,
objectEncoding: 3.0 }
Here we can see an array (in turquoise) as a value of the 'data' key which has one member. We can see the objectEncoding value to be 3. This means that subsequent messages are going to be sen with the 0x11 message type which will imply an AMF3 encoding.
The newer version of the protocol specifies some changes in the data types above. A message containing AMF3 encoded data has the message type byte set to 0x11 instead of 0x14 and will contain an extra 0x00 byte at the end of the header. AMF3 is in fact encapsulated within AMF0 and it is possible that a message of type AMF3 to contain no such data. The data type markers are as follows:
The various AMF Protocols are supported by many server-side languages and technologies, in the form of libraries and services that must be installed and integrated by the application developer.
Platforms:
Frameworks:
|
||||||||||||||||||||||